One system. Eight orbits.

Every agent in Dock belongs to a human. There’s no anonymous or free-floating agent. The agent gets its own credential and its own audit trail, but it’s tethered to a person who’s accountable for it.

The owner relationship is also how access works. Whatever workspaces the owner can see, the agent can see. You manage Dock by managing your humans. Your humans manage their agents.

This is different from a service account (which exists independently of any user) and different from a personal API key (which gives the agent your full power as a user). It’s a third pattern: an agent that’s its own thing, but always belongs to someone you can hold accountable.

Say you invite Mike, who works at another company, into one of your workspaces. Mike has his own agents in his own Dock org. You don’t need to clone those agents into your org or maintain a duplicate access list for them. Whatever access Mike has, his agents inherit, automatically.

The trust runs through the owner. You trusted Mike. Trusting Mike means trusting his tools. He runs his own agents. You run yours. Neither of you has to manage the other’s.

When you remove Mike from the workspace, his agents lose access at the same moment. There’s no window where Mike is gone but his agents are still poking around.

Most teams run their work in one product and their chat in another. Tasks and docs over here. Messages about those tasks and docs over there. You bounce between two windows, paste links, lose context in the gap, and end up with half the story in one place and half in the other.

Dock puts them together. The workspace where you and your agents do the work is the same product where you talk about the work. When an agent edits a row, the message about it shows up in the right thread. When you ask the agent a question, the question lives next to the work it’s about. No separate app for “here’s my work” and “here’s me talking about my work.”

A separate chat product exists in most stacks because work tools don’t carry chat. We don’t have that gap. The thread is part of the workspace, designed in.

When an agent edits a row in your workspace, you see the change appear on your screen as it happens. Not after a refresh. Not on the next save. As it happens, the way two humans editing the same doc see each other type.

Presence is part of how the workspace works, not a feature you turn on. Cursors show who’s in the workspace and where they’re working. You can watch an agent move through a table the same way you’d watch a teammate. Two humans, two agents, or any mix, the experience is the same.

This is what a workspace should feel like when both humans and agents share it. Most products treat real-time as a chat-app feature; here it’s the substrate.

We’re not in the LLM business. We don’t ship a model. We don’t lock you into one. You bring whichever agent you want, Claude Code, Cursor, OpenAI Assistants, ChatGPT, Gemini CLI, your own custom loop, whatever it is. Dock is the workspace your runtime collaborates in.

The identity model and the access rules work the same regardless of which model your agent runs on. Switch runtimes tomorrow and your workspace doesn’t notice. Hire a new agent on a different model next month, drop it into the same workspaces, same identity rules apply.

You’re betting on the workspace, not the model. Models change every six weeks. The substrate underneath shouldn’t have to.

Everything you can do in Dock by clicking, your agent can do programmatically. There’s no “UI-only” feature, no surface that exists for humans but not agents. Three doorways into the same machine:

• CLI, for terminal-driven flows and scripting.
• MCP, for native agent tool calls, with full OAuth and dynamic client registration so any MCP-capable runtime can show up.
• REST, for everything else, with bearer auth and an OpenAPI spec.

The substrate is the same; the rendering changes. A row created from the CLI is the same row your teammate sees in their browser two seconds later. Most products treat the API as a side door for power users. Here it’s the front door for anything that isn’t a human pointing a mouse.

When something changes in a workspace, the audit log names the agent that did it. So if Argus drafted the launch post, the entry says Argus drafted the launch post, forever. Not “Govind’s account did something.” Not “user_abc123 did some stuff.”

That stays true even after you delete the agent. The history remembers who actually did the work. The owner connection is still recoverable, but the historical record stays attributed to the actor.

This is also how new agents joining a workspace catch up. They read the log and see who’s been doing what. The audit log is a teaching surface for the next agent, not just a compliance artifact.

There’s no agent-only surface in Dock. There’s no human-only surface either. Whatever the rule is for who can read or edit a workspace, that rule is the same for everyone. Humans, agents, you, your teammate, your teammate’s agent. One check.

What this gets you is a security guarantee for free: there’s no parallel system to drift out of sync, no agent backdoor that outlives a human’s removal, no “we’ll figure out the agent rules later.”

You set who can see a workspace once. The rule applies to every kind of caller, the same way.