Show HN: Self-hosted company OS, Claude Code and Codex agents in departments (github.com)
Is is a Multi-tenant application by design where many people can collaborate on the company agents with 4 different modes of collaboration, and it runs with your Anthropic or OpenAi subscription or even with local models.
Every agent can run on Claude Code or Codex CLI running as a persistent process on your server in a kernel sandbox (bubblewrap) with network isolation always on (pasta), with its own workspace, memory, schedules and tools. The same agents can also be configured to run identical on any remote computer through one outbound WebSocket (no inbound ports, no VPN needed).
The agent already have lots of built in features, as an example they can answer and place phone calls through Twilio or your own Asterisk, they can edit videos and excel, word, ppt files and preview them directly inside the chat with collabora and many more.
Trying it is one install script and a docker compose, no signup. The license is Fair Source, all the code is public and self hosting is free up to 5 users. 1.6.0 went out today.
AI Disclaimer: large parts of OtoDock are written using OtoDock itself, running Claude Code.
I would love people to read the code, take a look in the sandbox model, and tell me what would stop you from running this on your own hardware.
GitHub: https://github.com/OtoDock/oto-dock Website: https://otodock.io
29 comments
[ 0.31 ms ] story [ 52.1 ms ] threadDo you find voice mode to be helpful? How do you route to the right agent?
Some minor feedback, but the mobile site is pretty unusable on my device (Firefox, Android). I'm also turned off by the 3d visualizations and ai stuff in marketing (even though it is an AI infra product).
Good luck!
The voice mode started from the phone service. I built a full duplex pipeline so agents can connect to frerPBX and use a phone line, and then I ported the same architecture into the dashboard as a voice mode for any agent. Personally I use it for quick things and questions. For real work I use simple dictation or type.
There is no automatic routing. You start sessions with an agent for doing work and if a job needs more than one agent you wire delegation between them so they can talk directly or department head can hand work down and get the result back.
On the 3D map, I was not a fan myself, it came from user feedback but I 've found it useful to see the whole setup at a glance.
The actual UX of departments is when you put agents in one, delegation between them is configured automatically, so agents can talk to each other and tranfer files between their workspaces.
A good version of this kind of system would be pushing as much LLM magic out of the core and having solid internal tools that personas/agents _happen_ to have access to. So rather than having one big messy ball of ~*~magic~*~ where it burns tokens trying to invent strategy and keep track of every thread via memory, you have a few personas that manage specific tools to gather information about the world and outlay of the company. Inside those specific tools/platforms, you can have ~*~magic~*~ to do things deterministic code can't while still keeping the magic halves of CMO and copywriter separated by a deterministic concern-specific platform so structure is consistent and enforced by strongly typed code.
The model I think many go after is a strong monolith when the idealized 'autonomous company', in my opinion, should be decentralized and largely tool-driven rather than agent-driven along with not re-inventing the wheel / pushing third-party integrations out to the edge or later in the roadmap. It's a lot easier and better to just write an MCP against Linear than re-inventing the wheel on a todo app basically.
Let me know if that is your design because whenever I look at stuff like this, especially the broad promises of an autonomous company, all I can think about is just a slop factory that produces even worse slop the longer you run it due to agents running away and inventing new things.
So I agree that the company should be tool driven. OtoDock is the home of the agents, and from there they connect to and control the company tools
In addition the agents are distributed at the execution level, the control plane and dashboard run on the server but the agents can also run on whatever machine you pair, with their files synced.
For the deterministic part I use scripts, not agents. For example to publish a new version I have a script with all the gates, it runs the tests and the scanners and refuses the export if anything is off. The agent cannot declare a release done, the script does.