I Built an Open-Source AI Engineering Company Instead of Another AI Agent
For the past year, AI coding agents have become incredibly cap...
For further actions, you may consider blocking this person and/or reporting abuse
Hey Mir! Been awhile since we won the Google Gemini Challenge. Glad you are doing well and good work on Orvix!
I am interested to know if you have stressed test your project to the limit. Is there someone Orvix can or cannot do? What was the most difficult thing you encountered?
helo my friend!! great to hear from you again, you are doing awesome too!
I'm actually still testing Orvix almost every day. Every mission helps uncover bugs, limitations, or areas where the core architecture can be improved. The goal is to keep making the engineering company more reliable and autonomous over time.
right now it can already handle fairly complex projects, but there are definitely edge cases and larger missions that I'm still improving like the hardest part hasn't been generating code, it's like getting multiple independent specialists to coordinate, recover from issues, and work together smoothly.
thank you so much you are still here and really appreciate the thoughtful question! and hope we get a chance to work together as well!
The open-source AI company idea is interesting because it forces the hard coordination questions early. Agents can generate activity, but an engineering company needs priority, ownership, acceptance criteria, and accountability when work is incomplete. The operating system matters as much as the agents.
thanks, Alex! I completely agree.
like for me, the interesting part isn't just the agents, it's everything around them. That's why Orvix puts so much emphasis on the operating model, like ownership through the Orvix Map, coordination via the Orvix Book, and review through Critic Council etc. Really appreciate your perspective!
That operating-model emphasis is the interesting part to me.
The agents themselves are the visible layer, but the hard question is always: who owns a decision, where does the plan live, what gets reviewed, and how does the system recover when two agents disagree or one agent is confidently wrong?
If Orvix Map, Orvix Book, and Critic Council make those boundaries explicit, that is the part worth stress-testing.
this is the part Orvix is trying to make explicit.
like the MasterMind agent owns mission-level decisions and conflict resolution, the Orvix Map is the locked source of truth for scope, contracts, ownership, files, and acceptance criteria, the Orvix Book is where specialists ask questions, record assumptions, negotiate handoffs, and surface disagreements, then ctiric council and may other reviewers reviews every PR against the map and sends incomplete or conflicting work back for revision.
If two agents still disagree, MasterMind sees the live Book context, task state, pr status, and runtime failures, then coordinates the resolution or reassigns the work. There’s also a wakeup pass for blocked tasks and a final runtime acceptance gate, so “confidently wrong” work isn’t treated as done just because code was produced.
I agree that this operating layer is what deserves the most stresstesting
That separation of Map, Book, reviewers, and mission-level arbitration is the part I would want to inspect first.
The interesting test is whether disagreement leaves durable evidence. If two specialists conflict, the system should preserve what each believed, which contract or file they relied on, what failed at runtime, and why MasterMind chose one path. Otherwise the orchestration can look coordinated while still losing the reason.
offcourse!! and a lot of that foundation is already built into Orvix. I’d genuinely love for you to test it once and see how the Map, Book, Critic Council, and MasterMind agent etc behave in a real mission. Feedback from developers like you is what will help make the system much stronger.
Swapping one giant shared conversation for a place where specialists ask targeted questions is the design choice I find most interesting, mostly because it's the thing real engineering teams get wrong too. The thing I keep wondering about the per-branch model is where the coordination cost lands. Real companies scale badly for exactly this reason, communication overhead grows faster than headcount, and if each specialist is its own context, two of them can make locally reasonable choices that only conflict at the merge. When a frontend and backend specialist disagree about the shape of an API, who actually holds the pen, and does that get settled in the Book up front or does the merge just surface it late?
thanks Nazar!! that's actually one of the core problems Orvix is trying to solve.
Right now, the Orvix Map acts as the shared contract, while the Orvix Book is where specialists clarify assumptions and coordinate before they start building. If conflicts still make it through, Critic Council and MasterMind step in during review to resolve them.
i'm still refining this coordination model, so feedback like yours is genuinely valuable. Really appreciate you taking the time to dive into it!
Really impressive one ! It would be great to see an option for adding custom knowledge/context to individual agents. It would really help them to run tasks effectively
ofcourse!!
really impressive feature u described and yes we are here to add more and more and improve the core architecture and overall experience and this overall experience improves from valuable feedbacks like yours one!!!
Interesting concept! Shifting from a single AI agent to a self-organizing AI engineering team is a creative approach that could improve collaboration, scalability, and software quality.
yes and that's what we are doing right now, testing with different missions and projects and improving the core!!
hope, u enjoyed reading this, would love to hear your valuable thoughts! 😊