Show HN: Evolving Agents Framework

github.com

138 points by matiasmolinas 3 days ago

Hey HN,

I've been working on an open-source framework for creating AI agents that evolve, communicate, and collaborate to solve complex tasks. The Evolving Agents Framework allows agents to:

Reuse, evolve, or create new agents dynamically based on semantic similarity Communicate and delegate tasks to other specialized agents Continuously improve by learning from past executions Define workflows in YAML, making it easy to orchestrate agent interactions Search for relevant tools and agents using OpenAI embeddings Support multiple AI frameworks (BeeAI, etc.) Current Status & Roadmap This is still a draft and a proof of concept (POC). Right now, I’m focused on validating it in real-world scenarios to refine and improve it.

Next week, I'm adding a new feature to make it useful for distributed multi-agent systems. This will allow agents to work across different environments, improving scalability and coordination.

Why? Most agent-based AI frameworks today require manual orchestration. This project takes a different approach by allowing agents to decide and adapt based on the task at hand. Instead of always creating new agents, it determines if existing ones can be reused or evolved.

Example Use Case: Let’s say you need an invoice analysis agent. Instead of manually configuring one, our framework: Checks if a similar agent exists (e.g., a document analyzer) Decides whether to reuse, evolve, or create a new agent Runs the best agent and returns the extracted information

Here's a simple example in Python:

import asyncio from evolving_agents.smart_library.smart_library import SmartLibrary from evolving_agents.core.llm_service import LLMService from evolving_agents.core.system_agent import SystemAgent

async def main(): library = SmartLibrary("agent_library.json") llm = LLMService(provider="openai", model="gpt-4o") system = SystemAgent(library, llm)

    result = await system.decide_and_act(
        request="I need an agent that can analyze invoices and extract the total amount",
        domain="document_processing",
        record_type="AGENT"
    )

    print(f"Decision: {result['action']}")  # 'reuse', 'evolve', or 'create'
    print(f"Agent: {result['record']['name']}")
if __name__ == "__main__": asyncio.run(main())

Next Steps Validating in real-world use cases and improving agent evolution strategies Adding distributed multi-agent support for better scalability Full integration with BeeAI Agent Communication Protocol (ACP) Better visualization tools for debugging Would love feedback from the HN community! What features would you like to see?

Repo: https://github.com/matiasmolinas/evolving-agents

kjhughes 3 days ago

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?

Splizard 2 days ago

> The second part demonstrates how agents communicate with each other through workflows defined in YAML

oh no

  • geodel 2 days ago

    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)

matiasmolinas 3 days ago

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.

  • thierrydamiba 3 days ago

    Cool project! Thanks for sharing.

    Intrigued by the storage-why not use a VDB?

matiasmolinas 17 hours ago

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!

phil-martin 2 days ago

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?

  • superb_dev 2 days ago

    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”
esafak 3 days ago

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?

  • hleszek 3 days ago

    As long as we don't ask it to make paperclips it should be fine.

  • ImHereToVote 2 days ago

    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.

mentalgear 2 days ago

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.

visarga 3 days ago

Feels like the JavaScript framework wars era all over again. Wondering what will be the prevailing paradigm.

  • Garlef 2 days ago

    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.

khaledh 3 days ago

There should be an image of Agent Smith somewhere in the readme (j/k) :)

  • antonkar 2 days ago

    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

  • thrance 3 days ago

    Sure would beat the cringe ugly AI image currently in the readme.

unification_fan 3 days ago

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

matiasmolinas 17 hours ago

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!