Fascinating concept, you essentially frame the backend not as a static codebase, but as an adaptive organism that evolves based on real-time usage.
A few things that come to my mind if I were to build this:
The 'Agent-User' Paradox: To make this work, you'd need the initial agents (the ones responding and testing the goals) to be 'chaotic' enough to explore edge cases, but 'structured' enough to provide meaningful feedback to the 'Architect' agent.
The Schema Contract: How would you ensure that as the backend "writes itself," it doesn't break the contract with the frontend? You’d almost need a JIT Documentation layer that updates in lockstep.
Verification: I wonder if the server should run the 'JIT-ed' code in a sandbox first, using the telemetry to verify the goal was met before promoting the code to the main branch.
It’s a massive shift from Code as an Asset to Code as a Runtime Behavior. Have you thought about how you'd handle state/database migrations in a world where the backend is rewriting itself on the fly? It feels to me that you're almost building a lovable for backend services. I've seen a few OS projects like this (e.g. MotiaDev) But none has executed this perfectly yet.
It's nerfed to a point that it feels more like lawyer than a coding assistant now. We were arguing about an 3rd party API ToU for 1 hour last night. VSC Copilot executed it within 1 minute.
To expand on the "Self-Healing" architecture mentioned in point #2:
The hardest mental shift for us was treating Exceptions as Observations. In a standard Python script, a FileNotFoundError is a crash. In Hive, we catch that stack trace, serialize it, and feed it back into the Context Window as a new prompt: "I tried to read the file and failed with this error. Why? And what is the alternative?"
The agent then enters a Reflection Step (e.g., "I might be in the wrong directory, let me run ls first"), generates new code, and retries.
We found this loop alone solved about 70% of the "brittleness" issues we faced in our ERP production environment. The trade-off, of course, is latency and token cost.
I'm curious how others are handling non-deterministic failures in long-running agent pipelines? Are you using simple retries, voting ensembles, or human-in-the-loop?
100% usability right now is not optimal. I'm releasing a new version of the documentation and installation process today. Sync and pull tomorrow, it should be a lot easier.
I really appreciate your efforts!There're so many valuable use cases that people can deliver via your CRM integration (e.g. leads automation, qualification, scoring, engagement, reporting, etc) It'd be great to test your HubSpot integration and see if these use cases can be brought to life.
That's indeed very hard - we're building runtime captures and they are fed to the coding agent (claude code, cursor, etc) to update the agents' codes. However, the runtime data needs to be structured in a certain way so the coding agents won't get confused. We're testing this a lot right now.
Interesting application - how'd you like to implement the credit-risk logics? Do you want to write SQL expressions, mathematical models via Python, or some other way? By design, the framework should containerize these logics. But it'd better learn more.
I grew up helping my dad run his factory so I'm very familiar with ERP systems for manufacturing. A few years ago, when I decided to build a startup and I indentified the biggest problems with ERP is the fact they all just serve as data integration and system of records now - there're not enough processes automation. Therefore, I thought it'd be very meaningful to leverage AI to automate business processes such as PO, Price Requisition, and invoices, etc.
3 years in, I realized that every customer in our space (construction and contracting) want process automation, however, AI is simply not good enough - it's too slow, unpredictable, inconsistent, and overall hard to count on. For example, automating a quote by asking AI to insert dynamic variables from a relational database is hit or miss. Asking voice AI to provide training does not capture full breadth of the offline activities. Asking AI to fill out a work order creates a ton of errors.
Later, we decided that though LLM and the foundation models were progressing fast, the dev tools were lacking way behind, particular behind all the hypes and promises these AI applications claimed. The agents are not reliable, consistent, intelligent, evolving, and chances are the market would demand more apps to keep the party going.
Therefore, we went full open-source. The mission we have in mind is really to "generate reliable agents that can run business processes autonomously". We see all this hype about general computer use (GCUs) and can't help but making an opposing argument - that the AI agents need guardrails, more defined paths, and most importantly consistent results just like a human would need
- Proactive Reasoning (anticipating future needs or consequences)
The project seems to have gained a bit of a traction so far and I hope that you can fork it and tell the community what's missing and what we should be working on. I deeply thank you because the it's truly painful to build and deploy these one-off agents that don't get utilized. (https://github.com/adenhq/hive).
I've been thinking about this a lot after shutting down my previous startup. One problem I've identified is that tools like Claude Co-worker or Claw Bots will never truly deliver reliable agentic outcomes for people due to the fact that scaling a human-like agent is paradoxically harder than scaling a script.
- I see a lot error propagation with CUAs
- A GUI is very flakey and it produces a lot action latency
- There're hidden states behind each screen that CUAs simply can't capture
- Token consumption is absurd (but I guess this will alleviate as LLMs get cheaper)
What do you guys think? Any good ideas what'd be a good counter to this?
A few things that come to my mind if I were to build this:
The 'Agent-User' Paradox: To make this work, you'd need the initial agents (the ones responding and testing the goals) to be 'chaotic' enough to explore edge cases, but 'structured' enough to provide meaningful feedback to the 'Architect' agent.
The Schema Contract: How would you ensure that as the backend "writes itself," it doesn't break the contract with the frontend? You’d almost need a JIT Documentation layer that updates in lockstep.
Verification: I wonder if the server should run the 'JIT-ed' code in a sandbox first, using the telemetry to verify the goal was met before promoting the code to the main branch.
It’s a massive shift from Code as an Asset to Code as a Runtime Behavior. Have you thought about how you'd handle state/database migrations in a world where the backend is rewriting itself on the fly? It feels to me that you're almost building a lovable for backend services. I've seen a few OS projects like this (e.g. MotiaDev) But none has executed this perfectly yet.