I Built an Open-Source AI Engineering Company Instead of Another AI Agent
For the past year, AI coding agents have become incredibly capable.
But almost all of them still follow the same idea:
One increasingly capable AI should build everything.
I wanted to explore the opposite.
What if the AI wasn't the engineer? What if it became the entire engineering company?
That's how Orvix started.
Meet Orvix
Orvix is a self-organizing AI engineering company.
You don't create agents manually or decide how many are needed.
You simply describe the mission.
From there, Orvix designs the project, creates exactly the specialists required for that mission, assigns ownership, coordinates their work, reviews their pull requests, and even creates entirely new specialists later if the project grows.
Every mission creates a different engineering company.
Building software like a real engineering team
Instead of one AI jumping between frontend, backend, infrastructure, testing and documentation, Orvix treats them as independent engineers.
Each specialist owns its own Git branch.
They work in parallel.
They negotiate decisions.
They review one another's work.
They communicate through the Orvix Book, a shared communication layer where engineers ask questions, request clarification, share discoveries, and coordinate their work instead of sharing one giant conversation.
The goal isn't just generating code.
It's organizing engineering.
Local first. Cloud when you need it.
One thing I wanted from the beginning was flexibility.
Orvix can run completely on your own machine if you want everything local.
Or you can deploy the Orvix runtime on Alibaba Cloud ECS, allowing anyone on your team to connect to the same engineering company remotely while every mission, every specialist, and the entire execution live on the server.
For this hackathon, Orvix was deployed on Alibaba Cloud and powered by Qwen Cloud (Alibaba Cloud Model Studio).
There's much more behind it
This post only scratches the surface.
The repository includes detailed documentation covering:
- the complete architecture
- the Orvix Map
- the Orvix Book
- the planning pipeline
- dynamic specialist creation
- mission lifecycle
- deployment on Alibaba Cloud
- and the reasoning behind the system's design.
If you're curious about how an AI engineering company actually works, I'd love for you to take a look.
Links
GitHub
https://github.com/abbasmir12/orvix
Documentation
https://github.com/abbasmir12/orvix/tree/main/docs
Demo
I'd love to hear what you think. If you have ideas for improving Orvix or thoughts about multi-agent engineering systems, feel free to share them.
Top comments (16)
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.
That separation is useful because it prevents the agent system from pretending one memory layer can do everything. The map helps navigate, the book preserves durable context, reviewers catch contested claims, and mission-level arbitration decides what actually matters. Mixing those roles is where systems get brittle.
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! 😊