The difference between an AI agent that chats and one that works is what it can reach. An agent with a role and a memory but no access to your repo, your calendar, or your inbox can only talk about the work. This is the guide to wiring one up properly. It takes minutes, and most of it turns out to be already done.
Step one is usually already done
There's no separate integrations setup in Dock. Your agents run on your own Claude account, so they inherit every tool connected to it: connect GitHub, Sentry, or Google Calendar to Claude once, and every agent you hire can use it. Claude handles the sign-in and keeps it authorized: nothing to re-authorize on the Dock side, no second copy of your credentials.
So the first move isn't in Dock at all: open your Claude account's connector settings and connect the services your team lives in. If you write code, start there: the repo, the error tracker, the deploy pipeline. That's where an agent's first useful act tends to be waiting.
To see what any agent can actually reach, open its side panel and go to Connectors. Everything inherited from your account is listed.
Everything the agent can reach, in one list: inherited from Claude on top, added by your team below, each with its own switch.
Add what Claude doesn't have
Some tools aren't in the connector catalog: an internal service, a niche API, something you run locally. Add those directly in Dock:
- Open Connectors in the agent's side panel and choose Add connector.
- Point it at the server: a name and the server's address, or the command that runs it for a local tool. Add a key if it needs one.
- Turn it on per agent. Connectors added this way are shared across your organization, and each agent can be switched on or off individually. Your researcher doesn't need the deploy tool, and shouldn't have it.
A name, an address, and an optional secret. The secret is injected at run time, kept out of chat and logs.
One thing worth knowing: tools resolve through your machine, so if an agent can't reach something you expected, check that the Mac app is running.
Keys, without pasting them into chat
Some jobs need an API key Claude doesn't hold: image generation, voice, a data provider. Pasting a key into chat is the wrong answer, because chat is a log. The Vault is the right one: store the key once in Settings → Vault, named after its environment variable, and it's sealed on submit. Your agents fetch it at the moment they need it, use it, and drop it. It's never shown in chat, never written to a file, and never shown back to you after you save it. Each key carries its own access list, so only the agents you name can pull it.
Names in the clear, values sealed on save. Nothing here to paste, nothing here to steal.
Set the permissions before the first job
Access and permission are separate dials, and that's deliberate. Every agent has its own permissions, set per kind of action: reading files, writing them, running commands, using the web, spawning subagents. Each one is Allow, Ask, or Deny.
One dial per kind of action. This agent browses freely and asks before it runs a command.
Ask is the useful middle setting. A new agent on unfamiliar work runs with Ask on the riskier kinds (running commands is the one most worth it), and you move it to Allow once you've watched it work. That's the same arc as trusting any new hire, which is exactly what it is.
Then give it a job that uses the wiring
A connected agent with nothing to do is still furniture. The fastest proof is a job that crosses two tools: have it read this morning's Sentry errors and open an issue for the real one, or pull today's calendar and prep the brief. When one agent is wired and working, the second use case is usually visible from the first: the same connectors that power a coding agent power an executive assistant, and the hire takes less time than the setup did.