What jumped out at me is how aggressively this project treats Claude Code and Codex as infrastructure, not just assistants. That’s interesting, and a little uncomfortable in the best possible way. The pitch is basically: bring your own subscription, self-host the control plane, and let agents loose across workspaces, machines, phones, schedules, and tools. That’s a much more opinionated vision than the usual “AI coding app” wrapper. It feels closer to an operating environment for agent labor.
I’m more convinced by the self-hosted, sandboxed, multi-tenant framing than by the “company OS” language. The OS rhetoric is doing a lot of work here. I don’t think anyone should read that literally. But the underlying idea — shared agents with clear roles, private vs shared workspaces, and per-agent permissions — does make sense. If you’re going to let agents act across a team, you need something much more structured than a chat window and a pile of prompts.
The part I’d actually want to try is the access model. The repo talks about kernel sandboxes, network isolation, scoped credentials, per-agent roles, and workspaces that can be private, shared, or both depending on mode. That’s the sort of thing most “agent” products hand-wave past. If it works as described, that’s a real step beyond toy demos. The interesting question is whether the ergonomics hold up once you stop admiring the architecture and start using it for messy real work.
I’m also skeptical of the breadth. It claims document editing, image and video pipelines, browser access, phone calls, terminal control, remote machines, meetings between agents, and a community catalog with lots of integrations. That’s a lot. Maybe that breadth is the point, but it also reads like the kind of feature pile where half the surface area is impressive in screenshots and only a narrow slice survives daily use. I’d want to know which pieces are genuinely polished and which are “supported” in the loose open-source sense.
The BYO subscription angle is clever. It lowers the cost of adoption and sidesteps some of the usual trust issues because the user keeps the model relationship. But it also means the product has to justify itself on orchestration, permissions, and workflow design, not on owning the model. That’s a harder business and a more honest one. If they can make that work, great. If not, it risks becoming a very elaborate dashboard around subscriptions people already have.
The demo claim is the one I’d treat with caution. “Directed, captured and edited by an OtoDock agent” is the sort of line that can mean anything from genuinely autonomous production to a heavily supervised showcase. Maybe it’s impressive; maybe it’s marketing. Without seeing the rough edges, I don’t know how much weight to put on it.
Still, I like that this repo is trying to define a real agent platform instead of another thin chat layer. Even if I’m not sold on the grand language, the combination of self-hosting, team roles, sandboxing, and per-user subscriptions is a more concrete direction than most of the LLM agent ecosystem manages.
