> ## Documentation Index > Fetch the complete documentation index at: https://docs.cobalt.peoplereign.io/llms.txt > Use this file to discover all available pages before exploring further. # How Cobalt works > The mental model behind Cobalt — agents, tools, channels, and identity. # How Cobalt works A few concepts explain almost everything in Cobalt. Once they click, the rest of the console is easy to navigate. ## An agent is an identity plus its tools An **Agent** is the thing your employees talk to. It has an identity — a name, a role, a personality, and safety boundaries — and it has a set of **tools** it can use to answer questions and get things done. Everything you configure for an agent is, ultimately, about its tools: which ones it has, and how they're allowed to behave. ## Capabilities are tools, granted three ways You give an agent capabilities by giving it tools. There's a clear order of preference: 1. **Integrations — the primary way.** An [Integration](/integrations/overview) connects the agent to an external system (your service desk, HRIS, identity provider, file store, and so on) and turns that system's capabilities into tools the agent can call. Reach for an integration first. 2. **Skillsets — for what an integration can't do.** When no integration covers what you need — a bespoke internal API, an unusual workflow — you author a [Skillset](/build-agent/skillsets-and-skills): a small set of natural-language **Skills** that tell the agent how to do the job, with credentials supplied by a **skillset configuration**. Skillsets are the exception path, not the default. 3. **Custom knowledge — for one-offs.** For reference material that doesn't live in a connected system — a policy PDF, an internal FAQ — add [custom knowledge](/build-agent/custom-knowledge) the agent can search and cite. Rule of thumb: **Integration → Skillset → Custom knowledge.** If a connected system can do it, use the integration. Only drop down a level when the level above genuinely can't. ## Rules and hooks control how tools behave Once an agent has tools, you control how they're allowed to act with a layered set of guardrails — see [tools, rules & hooks](/build-agent/tools-rules-and-hooks): * **Family rules** apply to a whole family of tools at once (for example, which domains the web tools may reach). * **Per-tool rules** override the family rule for a single tool. * **Hooks** are policy gates that run at the moment a tool is called — they can require confirmation, check a value against an allowlist, or deny outright. Privileged actions (resetting a password, changing a record) are gated this way by default, and every such action is written to an audit trail. ## Channels are where the agent meets people A **[Channel](/channels/overview)** is how employees reach the agent: the embeddable web widget, Slack, and more. One agent can serve several channels at once. An agent with no channel is invisible — connecting a channel is what makes it live. ## Identity connects a request to a person When a request arrives, Cobalt resolves *who* is asking so the agent can act on their behalf and apply the right policy. Administrators sign in to the console through your SSO provider; end users are identified per channel, and **Identity Rules** map an inbound user (a Slack ID, an email) to a known person. See [Identity & access](/identity/overview). ## Where to go next Profile, capabilities, skillsets, and tools. Connect external systems — the primary capability path. Put your agent in front of employees. Every term in one place.