This seems a lot like Cloudflare OS (https://blog.cloudflare.com/cloudflare-os/). Is that a fair comparison? If so I'd be keen to understand how this differs aside from not being baked into the Cloudflare estate.
Fair comparisons. Paperclip does the org chart and the orchestration but it depends on other runtimes to actually run the agents. OtoDock also runs on Claude Code and Codex, the difference is the agents run inside it, as persistent processes in a sandbox on your server. Or also you can pair one of your machines with one command and you make any agent run on it with its tools and files synced to the platform, with automatic fall back to the server when the machine is offline. Cloudflare OS I only know from their post, so I cannot compare it properly yet.
Need of the hour, with Claude code subscriptions being allocated by the organisation based on project priority. this bring your own subscription is thoughtful.
I work on a realtime collaboration platform, and I've been building something similar for internal use - cool to see your mental model.
Do 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).
Thank you for checking this out and for your feedback, I will check Firefox now!
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.
If you organize agents by department, who verifies an agent's 'completion' report? In my experience, reviews using the same model rarely caught its own mistakes—only a different model or execution receipts (rc·sha256·stderr) caught them. How are you handling this here?
OtoDock does not verify a report by itself, but you can set it up in your installation. A delegated agent runs as a normal session on the platform, so the whole run is persisted, every tool call and its output, and both the delegating agent and a human can open that session instead of trusting the summary. Delegation can also pin a different model or engine per lane, so the reviewer can run on Codex or a local model while the worker ran on Claude.
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.
The map is mainly there to see the whole installation at a glance. The departments, the agents in them and who delegates to whom. There is a plain grid view as well.
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.
Looks great. I didn't like the paperclip system with my main issue being that agents would go over daily budgets all too often. Looking forward to giving this a try.
I have been playing with something similar and I see these types of projects all the time. My criticism of things like this is that they seem to rely heavily on the ~*~magic~*~ of LLMs to do everything and try to paper over gaps with major hand-waving on everything beyond "agents do everything" when in reality, the most critical part is agents NOT doing much and relying on 'boring' deterministic backbones in an automatic fashion.
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.
I agree with your points, and that is how it is built. The backbone in OtoDock is deterministic code, the model only runs inside a session. Schedules are cron, triggers are webhooks, permissions are a fail closed gate per tool, cost limits are set per user and per agent, and delegation between agents is configured from the admin and the agent managers, an agent cannot change any of that. Agents only see the tools and skills their manager assigned and the integrations are MCPs against existing tools, GitHub, Notion, Home Assistant, Prometheus. Memory is plain markdown files you can read and edit.
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.
This seems a lot like Cloudflare OS (https://blog.cloudflare.com/cloudflare-os/). Is that a fair comparison? If so I'd be keen to understand how this differs aside from not being baked into the Cloudflare estate.
Also seems very similar to Paperclip (https://paperclipai.net/). It's a "company" with an org chart of agents.
Fair comparisons. Paperclip does the org chart and the orchestration but it depends on other runtimes to actually run the agents. OtoDock also runs on Claude Code and Codex, the difference is the agents run inside it, as persistent processes in a sandbox on your server. Or also you can pair one of your machines with one command and you make any agent run on it with its tools and files synced to the platform, with automatic fall back to the server when the machine is offline. Cloudflare OS I only know from their post, so I cannot compare it properly yet.
Need of the hour, with Claude code subscriptions being allocated by the organisation based on project priority. this bring your own subscription is thoughtful.
I work on a realtime collaboration platform, and I've been building something similar for internal use - cool to see your mental model.
Do 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!
Thank you for checking this out and for your feedback, I will check Firefox now!
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.
If you organize agents by department, who verifies an agent's 'completion' report? In my experience, reviews using the same model rarely caught its own mistakes—only a different model or execution receipts (rc·sha256·stderr) caught them. How are you handling this here?
OtoDock does not verify a report by itself, but you can set it up in your installation. A delegated agent runs as a normal session on the platform, so the whole run is persisted, every tool call and its output, and both the delegating agent and a human can open that session instead of trusting the summary. Delegation can also pin a different model or engine per lane, so the reviewer can run on Codex or a local model while the worker ran on Claude.
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.
I need to understand what is the UX of departments. 3d animated wood panels on a forest floor??
The map is mainly there to see the whole installation at a glance. The departments, the agents in them and who delegates to whom. There is a plain grid view as well.
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.
I think it's just missing the high walls between each.
Looks great. I didn't like the paperclip system with my main issue being that agents would go over daily budgets all too often. Looking forward to giving this a try.
Glad you like it. If you test it out I would love any feedback!
I have been playing with something similar and I see these types of projects all the time. My criticism of things like this is that they seem to rely heavily on the ~*~magic~*~ of LLMs to do everything and try to paper over gaps with major hand-waving on everything beyond "agents do everything" when in reality, the most critical part is agents NOT doing much and relying on 'boring' deterministic backbones in an automatic fashion.
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.
I agree with your points, and that is how it is built. The backbone in OtoDock is deterministic code, the model only runs inside a session. Schedules are cron, triggers are webhooks, permissions are a fail closed gate per tool, cost limits are set per user and per agent, and delegation between agents is configured from the admin and the agent managers, an agent cannot change any of that. Agents only see the tools and skills their manager assigned and the integrations are MCPs against existing tools, GitHub, Notion, Home Assistant, Prometheus. Memory is plain markdown files you can read and edit.
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.