OtoDock, a new “Show HN” project, is pitching a different way to deploy AI agents at work: not as isolated chatbots, but as a self-hosted operational layer where teams assign agents to departments, connect approved tools and review the work those agents produce.
The project runs on a company’s own server and can use Claude Code through Anthropic subscriptions, Codex through ChatGPT subscriptions, API keys, or local models. Its code is available under the Fair Source License 1.1 with a future Apache 2.0 license, rather than a conventional open-source license.
What changed
At its core, [OtoDock](https://github.com/OtoDock/oto-dock) combines several agent patterns that are often assembled separately: persistent instructions and memory, documents and workspaces, tool permissions, scheduled or webhook-triggered runs, and a shared dashboard.
An agent has a defined persona, memory, workspace, knowledge base, skills and a restricted tool set. Teams can place agents in departments, set delegation relationships and run multi-agent “meetings.” The interface also supports live dashboards, in-chat document editing, terminal access for Claude Code or Codex, and notifications for work requiring human attention.
The project’s collaboration model is more notable than the “digital employee” framing. It offers four workspace modes, ranging from a completely personal history and workspace to one shared by the whole team. It also distinguishes platform administration from per-agent roles such as manager, editor, member and viewer.
For execution outside the browser, OtoDock says agents can be triggered on a schedule, by webhook or manually. It can also pair macOS, Linux and Windows machines through an outbound connection, allowing an agent to work against a paired machine’s environment while retaining a central dashboard. A server-side fallback is intended to take over when that machine is offline.
Why it matters to operators
Enterprise agent deployments tend to break down at the boundary between a useful prototype and a system people can share safely. A coding agent may be capable of changing files or calling services, but operators still need to answer basic questions: Which team owns it? Which data and tools can it reach? Where does its output go? Who can inspect or continue a run?
OtoDock treats those questions as product primitives. Its shared versus personal workspace modes could be useful for teams that want a common operational agent—for example, for triage or reporting—without turning every user interaction into shared history. Per-agent roles may similarly give teams a way to separate people who configure an agent from people who simply use it.
The self-hosted approach also changes the procurement conversation. Organizations can keep the orchestration layer and workspaces in their own environment while choosing model back ends per agent or even per chat. But self-hosting shifts responsibility for deployment, updates, monitoring, identity controls and incident response to the customer.
Security and governance are the real test
OtoDock says server-side agents run in isolated kernel sandboxes with network isolation and service-by-service access grants. That is the right direction for software that can access tools, files and remote machines. Still, the project’s claims should be evaluated in a real environment before broad access is granted.
Teams should start with narrow, reversible workflows: read-only reporting, document drafting or ticket classification. They should verify auditability of runs and tool calls, test whether permissions behave as expected across shared workspaces, and establish explicit approval points before agents modify production systems or communicate externally. Connecting a phone line through Twilio, Asterisk or FreePBX raises another set of controls around identity, recording and escalation.
What to watch next
The key question is whether OtoDock can make agent operations more manageable than a collection of scripts, chat interfaces and vendor-specific consoles. Watch for maturity in access control, logging, deployment documentation and integrations—not just the breadth of the dashboard.
For builders, its model-neutral stance is also worth watching. If teams can switch between subscription-backed coding agents, API-driven models and local models without rebuilding workflows, the orchestration layer may become more durable than any one model provider. The hard part will be delivering that flexibility without making governance and reliability harder to operate.
