i have been working on something similar, trying to build the leanest agent loop that can be self modifying. ended up building it as a plugin within OpenCode with the cow pulled out into python hooks that the agent can modify at runtime (with automatic validation of existing behavior). this allows it to create new tools for itself, customize it's system prompt preambles, and of course manage its own traits. also contains a heartbeat hook. it all runs in an incus VM for isolation and provides a webui and attachable TUI thanks to OpenCode.
Show HN: Agent framework that generates its own topology and evolves at runtime
31–40 of 53 posts
Re: Show HN: Agent framework that generates its own topology and evolves at runtime
#32> The topology shouldn't be hardcoded; it should emerge from the task's entropy
What does this even mean?
Re: Show HN: Agent framework that generates its own topology and evolves at runtime
#33Hive looks like a promising framework for AI agents. I recently contributed a docs PR and found the onboarding experience improving quickly. Excited to see where this goes.
Re: Show HN: Agent framework that generates its own topology and evolves at runtime
#34[flagged]
Re: Show HN: Agent framework that generates its own topology and evolves at runtime
#35The comments on this post that congratulate/engage with OP all seem to be from hn accounts created in the past three months that have only ever commented on this post, so it seems like there is some astro-turfing going on here.
It’s super bad on this post. The llm’s sometimes are breaking character even.
Re: Show HN: Agent framework that generates its own topology and evolves at runtime
#36Interesting direction. I agree that most agent frameworks hit a “toy app ceiling” because they conflate conversational state with long-lived system state. Once you move into real business workflows (ERP, reconciliation, async pipelines), the problem stops being prompt orchestration and becomes distributed state management under uncertainty.
The OODA framing is compelling, especially treating exceptions as observations rather than terminal states. That said, I’m curious how you’re handling:
1.State persistence across long-running tasks — is memory append-only, event-sourced, or periodically compacted?
2.Convergence guarantees in your “system of inference” model — how do you prevent correlated failure across k runs?
3.Cost ceilings — at what point does reliability-through-redundancy become economically infeasible compared to hybrid symbolic validation?
I also like the rejection of GCU-style UI automation. Headless, API-first execution seems structurally superior for reliability and latency.
The biology-inspired control mechanisms (stress / neuroplasticity analogs) are intriguing — especially if they’re implemented as adaptive search constraints rather than metaphorical wrappers. Would be interested to understand how measurable those dynamics are versus heuristic.
Overall, pushing agents toward durable, autonomous services instead of chat wrappers is the right direction. Curious to see how Hive handles multi-agent coordination and resource contention at scale.
Re: Show HN: Agent framework that generates its own topology and evolves at runtime
#37Oh hey aren't you the folks that grabbed all the stargazers of an open source project and their emails and sent out unsolicited ads?
Re: Show HN: Agent framework that generates its own topology and evolves at runtime
#38This looks so cool and more noncoder friendly over hardcoded workflows, that's the exactly what most builders need
Re: Show HN: Agent framework that generates its own topology and evolves at runtime
#39I’ve been exploring Hive recently and what stands out is the move from prompt orchestration to persistent, stateful execution. For real ERP-style workflows, that shift makes sense.
Treating exceptions as observations instead of terminal failures is a strong architectural reframing. It turns brittleness into a feedback signal rather than a crash condition.
A few production questions come to mind:
1) In the k-of-n inference model, how do you prevent correlated failure? If runs share similar prompts and priors, independence may be weaker than expected.
2) How is memory managed over long-lived tasks? Is it append-only, periodically compacted, or pruned strategically? State entropy can grow quickly in ERP contexts.
3) How do you bound reflection loops to prevent runaway cost? Are there hard ceilings or confidence-based stopping criteria?
I strongly agree with the rejection of UI-bound GCU approaches. Headless, API-first automation feels structurally more reliable.
The real test, in my view, is whether stochastic autonomy can be wrapped in deterministic guardrails — especially under strict cost and latency constraints.
Curious to see how Hive evolves as these trade-offs become more formalized.
Re: Show HN: Agent framework that generates its own topology and evolves at runtime
#40I am Frontend Engineer have hands on experience with React, JavaScript, Tailwindcss, HTML, CSS, API Integration